Cloud-Based Transaction Processing

ABSTRACT

A peripheral controller implemented on a server facilitates a transaction initiated at a payment user interface (UI). The peripheral controller is configured to pair the payment UI with a peripheral device, which is configured to receive payment information from a user. The peripheral controller also is configured to communicate with a payment processing system to facilitate processing of a payment request.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. application Ser. No.16/194,615 entitled “CLOUD-BASED TRANSACTION PROCESSING,” filed Nov. 19,2018 (now U.S. Pat. No. 11,475,429), which was a continuation of U.S.application Ser. No. 14/410,281 entitled “CLOUD-BASED TRANSACTIONPROCESSING,” filed Dec. 22, 2014 (now U.S. Pat. No. 10,152,704), whichis a U.S. National Phase application under 35 U.S.C. § 371 ofPCT/US2013/032120 filed Mar. 15, 2013 which claimed priority to U.S.Provisional Application No. 61/664,382, entitled “METHOD TO DECOUPLEPAYMENT PERIPHERALS FROM USER INTERFACE,” filed on Jun. 26, 2012. Eachof these applications are hereby explicitly incorporated herein, intheir entirety, by reference for all purposes.

BACKGROUND

The process of taking non-cash payments from customers is crucial to theflow and success of business. This process generally involves a paymentuser interface (UI) implemented on a computing device (e.g., apoint-of-sale (POS) device or a laptop computer) and one or moreattached peripheral devices. The payment UI generally includes softwaredesigned to guide a user (e.g., a salesperson or cashier) through theprocess of gathering information from the customer, product, and/orservice, and presenting a total amount due. In current systems, thepayment UI interacts with various attached peripheral devices such as,for example, payment card readers, PIN pads, check readers, and receiptprinters.

For example, the arrangement is often implemented as a check-outterminal that consists of a payment UI implemented on a computing devicethat is coupled to peripheral devices using cables (e.g., serialcables). Payment information is processed by the payment UI, causing theentire network and computer systems infrastructure supporting theconfiguration to be within the scope of Payment Card Industry (PCI)Compliance. Conventional payment processing arrangements involveadditional limitations, as well. For example, each peripheral devicegenerally requires a driver that must be installed at the payment UIlocation and physical mobility generally is not possible with thepayment UI because the device on which it is implemented is physicallyconnected to the peripheral devices. Browser support is often limited asweb-based payment UI applications need to interact with local hardwaresuch as, for example, by using Active X controls, which are oftenunreliable when implemented within secure communication environments.Furthermore, application programming interfaces (APIs) used tocommunicate with peripheral devices typically are not straightforward orstandardized; and therefore, to implement peripheral devices in apayment solution, one often must learn a unique API for each peripheraldevice manufacturer.

SUMMARY

Embodiments of the present invention provide for decouplingcommunications between peripheral devices and payment UIs, allowing fora flexible and/or mobile sales checkout experience and minimizingexposure of local devices and networks to PCI scope. According toembodiments, a peripheral device is paired with a payment UI instance bya peripheral controller that is implemented on a server. Paymentinformation provided to the peripheral device is processed through theserver, thereby avoiding exposure of the payment information to thepayment UI.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating an operating environment (and, insome embodiments, aspects of the present invention) in accordance withembodiments of the present invention;

FIG. 2 is a schematic diagram depicting an illustrative pairingoperation in accordance with embodiments of the present invention;

FIG. 3 is a schematic diagram depicting an illustrative transactionoperation in accordance with embodiments of the present invention; and

FIG. 4 is a flow diagram depicting an illustrative method offacilitating a transaction in accordance with embodiments of the presentinvention.

While the present invention is amenable to various modifications andalternative forms, specific embodiments have been shown by way ofexample in the drawings and are described in detail below. The presentinvention, however, is not limited to the particular embodimentsdescribed. On the contrary, the present invention is intended to coverall modifications, equivalents, and alternatives falling within theambit of the present invention as defined by the appended claims.

Although the term “block” may be used herein to connote differentelements of illustrative methods employed, the term should not beinterpreted as implying any requirement of, or particular order among orbetween, various steps disclosed herein unless and except whenexplicitly referring to the order of individual steps.

DETAILED DESCRIPTION

Embodiments of the present invention facilitate transactions involvingnon-cash payments by providing a cloud-based payment solution in whichperipheral devices need not be physically coupled to a payment nodeimplementing a payment UI. This allows for, e.g., a payment made to beflexibly coupled to any number of peripheral devices within a givenfacility. Additionally, embodiments of the present invention may enablemore secure use of traditional arrangements in which peripheral devicesare physically coupled to the payment node by enabling the peripheraldevices to communicate with a server rather than the payment UI.Embodiments of the invention may enable the payment UI to be implementedon a variety of platforms, which need not be restricted to environmentsguaranteeing device driver support for the peripheral devices.

In embodiments, a server-based peripheral controller (which may beimplemented, e.g., in a cloud environment) facilities pairing paymentUIs with peripheral devices and facilitates transaction flows betweenthe payment UIs and the paired peripheral devices. Pairing refers to aprocess of associating a payment UI with a peripheral device, and may beused to facilitate a virtual connection between the payment UI and theperipheral device. In embodiments, a peripheral device may bedynamically associated with any given payment UI at any given time, andany number of peripheral devices may be associated with any number ofpayment UIs. Additionally, because the connection between a payment UIand a peripheral device is virtual, the payment UI and the peripheraldevice may be remotely located from each other. Embodiments of theinvention also provide a standard interface configured to operate withperipheral devices from disparate vendors, allowing merchants to chooseperipheral devices from any desired vendor without needing to learn aunique interface associated with each vendor. By implementingembodiments of the invention, transactions may be processed withoutexposing sensitive payment information (e.g., in a “clear text” form) tothe merchant's devices or network.

FIG. 1 depicts an illustrative operating environment 100 (and, in someembodiments, aspects of the present invention) in accordance withembodiments of the present invention as illustrated by way of example.As shown in FIG. 1 , embodiments of the operating environment 100include a network 101 through which a server 102, which may beimplemented as a component of a payment gateway 103, facilitates pairingone or more peripheral devices 104 and 106 with a payment UI 108. Thenetwork 101 may be, or include, any number of different types ofcommunication networks such as, for example, a local area network (LAN),a wireless LAN (WLAN), a wide area network (WAN), the Internet, or thelike. Components of the operating environment 100 may communicate usingsecured communications, which may include encryption, certificates,tunneling protocols, virtual private networks (VPNs), and the like. Forexample, communications over the network 101 may be secured usingTransport Layer Security (TLS), Secure Sockets Layer (SSL), or acombination of these.

As shown in FIG. 1 , the payment UI 108 may be implemented in a browser110 hosted by a payment node 112. As the name implies, the payment node112 is, in embodiments, what a merchant uses to initiate a transactionand includes a display 114. In embodiments, the payment node 112 mayinclude any type of computing device capable of hosting a browser 110that provides a payment UI 108, which may be presented on the display114. The payment UI 108 may be provided by, and/or interact with, apayment processing system 116. For example, the payment processingsystem 116 may include a web server that provides a web page containingthe payment UI 108. In embodiments, the payment UI 108 may beimplemented using web services, thin client applications, localapplications, or the like.

As shown in FIG. 1 , the payment node 112 includes a processor 118 and amemory 120. According to embodiments, the payment node 112 includes acomputing device and may, for example, take the form of a specializedcomputing device (e.g., a point-of-sale (POS) device) or ageneral-purpose computing device such as a personal computer,workstation, personal digital assistant (PDA), mobile device,smartphone, tablet, notebook, or the like. In embodiments, the browser110 may be stored in the memory 120 and, in embodiments, at least aportion of the payment UI 108 may be stored in the memory 110, forexample, as a thin client application. The processor 118 may instantiatethe browser 110, which causes at least a portion of the payment UI 108to be displayed on the display 114. The browser 110 also may facilitateother operations and interactions associated with a transaction such as,for example, receiving transaction information from a user, receivingpayment confirmation from the payment gateway 103, generating a paymentreceipt, and the like, as explained in greater detail below.

The payment UI 108 may facilitate transactions by communicating with theserver 102 via a UI/gateway interface (UGI) 142. The UGI 142 may be, orinclude, any type of interface that enables communications between apayment UI 108 and a server 102 such as, for example, an applicationprogramming interface (API). In embodiments, a portion of the UGI 142may be stored in the memory 120 of the payment node 112 and a portionmay be stored in a memory 126 of the server 102. In embodiments, thepayment UI 108 may communicate directly with the payment processingsystem 116.

As shown in FIG. 1 , the server 102 also includes a processor 122 and amemory 124, and may be, or include, any type of computing device capableof providing one or more service functions in accordance with aspects ofembodiments of the invention, as described herein. As illustrated, theserver 102 and the payment processing system 116 may be implemented ascomponents of the payment gateway 103. The payment processing system 116may be implemented using a device other than the server 102 and, inembodiments, the payment processing system 116 may be implemented on theserver 102. For example, the payment processing system 116 and theperipheral controller 126 may each be implemented using separate virtualmachines that are hosted by the same computing device or set ofcomputing devices.

The peripheral controller 126 may be stored in the memory 124. Inembodiments, the processor 122 executes the peripheral controller 126,which may facilitate pairing one or more peripheral devices 104 and 106with the payment UI 108, manage pairings, facilitate transactionpayments, and the like. The peripheral controller 126 may include apairing module 128 and a transaction module 144. The pairing module 128and the transaction module 144 may communicate with the peripheraldevices 104 and 106 via a peripheral/gateway interface (PGI) 130. ThePGI 130 may be, or include, any type of interface that enablescommunications between a peripheral device 104 or 106 (or a hub 140, asdiscussed below) and the peripheral controller 126 such as, for example,an API. In embodiments, a portion of the PGI 130 may be stored in thememory 124 of the server 102 and a portion may be stored in a memory 134of a peripheral device 104 or a peripheral hub 140.

Information associated with a pairing may be stored in a database 132 inthe memory 124. The database may be, or include, a table, a relationaldatabase, a multi-dimensional cube, and the like. Embodiments of theserver 102 also include an administrative portal (not shown) that allowsadministrators to access the database 132 and/or otherwise determinewhich peripheral devices are paired with which payment UIs. For example,the server 102 may maintain administrator accounts such thatadministrators may provide credentials (e.g., passwords) and may beprovided access, based on a set of associated permissions to portions ofdata stored in the database 132.

As shown in FIG. 1 , in embodiments, the peripheral device 104 may be“aware” of the server 102 (e.g., configured to communicate with theserver 102) and may include a memory 134, a processor 136 and one ormore input/output (I/O) devices 138. Examples of I/O devices 138include, without limitation, magnetic card readers, scanners, keypads,PIN pads, display devices, and the like. As illustrated, in other orconsistent embodiments, the peripheral device 106 may not be aware ofthe server 102 and may be connected (e.g., via a wired or wirelessconnection) to a peripheral hub 140 that communicates with the server102 via the PGI 130. Thus, the hub 140 facilitates communication betweenthe server 102 and other devices that otherwise would not readily beable to communicate with the server 102. According to embodiments, theperipheral hub 140 may be, or include, software, firmware, hardwareand/or a combination of these.

For example, in embodiments, the peripheral hub 140 may include ahardware device having a number of physical communication ports (e.g.,universal serial bus (USB) ports) to which one or more peripheraldevices 106 may be coupled. In aspects of this example, peripheral hub140 may register the one or more peripheral devices 106 such that, uponconnecting a peripheral device 106 to the peripheral hub 140, a pairingbetween the peripheral device 106 and the payment UI 108 may beestablished automatically. In embodiments, the peripheral hub 140 may bea component of a peripheral device 104 (e.g., a check reader) that alsoincludes physical communication ports to which another peripheral 106(e.g., a receipt printer) may be coupled.

In embodiments, using a peripheral hub 140 may facilitate implementationof a payment node 112 to which one or more peripheral devices 104 arephysically connected (e.g., an arrangement in which the payment node 112implements a web-based payment UI application 108 that is configured toreceive payment information from a local peripheral device). That is,the peripheral hub 140 may be, or include, one or more softwarecomponents stored in the memory 120 of the payment node 112 that, whenexecuted by the processor 118, facilitate communications between one ormore local peripheral devices that are registered with the peripheralhub 140 and the server 102. For example, the peripheral hub 140 may be asoftware component that serves as a communication bridge between the oneor more local peripheral devices and the server 102. In this manner,embodiments of the invention enable peripheral devices to communicateinformation to the server 102, and vice versa, while avoiding thechallenges of traditional communications with local hardware implementedusing Active X controls. In configurations such as these, for example,end-to-end encryption techniques may be used to prevent exposure ofpayment information to aspects of the payment UI 108.

According to embodiments, various components of the operatingenvironment 100, illustrated in FIG. 1 , can be implemented on one ormore computing devices. For example, each of the server 102, theperipheral devices 104 and 106, the payment node 112, the paymentprocessing system 116, and the hub 140 may be, or include, one or morecomputing devices. A computing device may include any type of computingdevice suitable for implementing embodiments of the invention. Examplesof computing devices include “workstations,” “servers,” “laptops,”“desktops,” “tablet computers,” “hand-held devices,” “POS devices,”“card readers,” “check readers,” and the like, all of which arecontemplated within the scope of FIG. 1 and reference to variouscomponents of the operating environment 100.

In embodiments, a computing device includes a bus that, directly and/orindirectly, couples the following devices: a processor, a memory, aninput/output (I/O) port, an I/O component, and a power supply. Anynumber of additional components, different components, and/orcombinations of components may also be included in the computing device.The bus represents what may be one or more busses (such as, for example,an address bus, data bus, or combination thereof). Similarly, inembodiments, the computing device may include a number of processors, anumber of memory components, a number of I/O ports, a number of I/Ocomponents, and/or a number of power supplies. Additionally any numberof these components or combinations thereof may be distributed and/orduplicated across a number of computing devices.

In embodiments, the memories 120, 124, and 134 include computer-readablemedia in the form of volatile and/or nonvolatile memory and may beremovable, nonremovable, or a combination thereof. Media examplesinclude Random Access Memory (RAM); Read Only Memory (ROM);Electronically Erasable Programmable Read Only Memory (EEPROM); flashmemory; optical or holographic media; magnetic cassettes, magnetic tape,magnetic disk storage or other magnetic storage devices; datatransmissions; or any other medium that can be used to encodeinformation and can be accessed by a computing device such as, forexample, quantum state memory, and the like. In embodiments, thememories 120, 124, and 134 store computer-executable instructions forcausing the processors 118, 122, and 136, respectively, to performaspects of embodiments of methods and procedures discussed herein.Computer-executable instructions may include, for example, computercode, machine-useable instructions, and the like such as, for example,program components capable of being executed by one or more processorsassociated with a computing device. Examples of such program componentsinclude the browser 110, the payment UI 108, the pairing module 128, thePGI 130, the database 132, the UGI 142, and the transaction module 144.Some or all of the functionality contemplated herein may also beimplemented in hardware and/or firmware.

The illustrative operating environment 100 shown in FIG. 1 is notintended to suggest any limitation as to the scope of use orfunctionality of embodiments of the present invention. Neither shouldthe illustrative operating environment 100 be interpreted as having anydependency or requirement related to any single component or combinationof components illustrated therein.

FIG. 2 is a schematic diagram depicting an illustrative pairingoperation in accordance with embodiments of the present invention.According to embodiments, the pairing operation may be accomplishedusing hypertext markup language (HTTP) communications such as, forexample, the HTTP POST process, which is a synchronous process thatutilizes requests and responses. By implementing pairing processes usingHTTP POST, pair requests may be timed out if a response is not receivedafter a specified amount of time. Additionally, in embodiments, HTTPPOST communications flow through firewalls and proxies with relativeease, thereby minimizing the technical effort expended in implementingaspects of embodiments of the invention.

As shown in FIG. 2 , a peripheral 104 (or a hub 140, acting on behalf ofa peripheral 106) provides a pair request 202 to the pairing module 128of the peripheral controller 126. The pair request 202 may be provided(and received by the pairing module 128) using the PGI 130 and may becreated using any number of different formats such as, for example,extensible markup language (XML). A pairing between a peripheral 104 or106 and a payment UI 108 may be identified using a unique identifier,referred to herein as a “pair ID.” According to embodiments, a pairingoperation may be an open pairing operation (in which the peripheral 104,or hub 140, generates the pair ID), or a closed pairing operation (inwhich the pairing module 128 generates the pair ID).

In embodiments, for example, aspects of an open pairing operation may beused for pairing a peripheral device that is coupled to, or integratedwith, the payment node 112. For example, the payment node 112 mayinclude a peripheral hub 140 (e.g., software executable by the browser110) that registers one or more local peripheral devices. The pairingmodule 128 may store a hub ID in the database 132 and associate the hubID with the payment UI 108. Upon pairing a local peripheral device withthe payment UI, the pairing module 128 may provide a cookie to theperipheral hub 140, which is stored in the memory 120 such that, whenthe payment node 112 is activated and/or communicates with the server102, the cookie may be provided to the pairing module 128, therebyfacilitating an automatic pairing of the local peripheral device withthe payment UI 108. For example, a JavaScript executed by the browser110 may register the payment UI 108 with the pairing module 128 and thecookie may facilitate access to the pairing module 128, via a singleuniform resource locator (URL), by both the peripheral hub 140 and thepayment UI 108.

In an open pairing operation, the pair request 202 may include anindication of the type of communication, an indication of a peripheraldevice type, and an identifier of the peripheral device 104, as well asa pair ID. According to embodiments, the pair ID may be generated basedon a user input such as, for example, a payment card number or achecking account number. For example, in embodiments in which theperipheral 104 includes a magnetic card reader, a user may swipe apayment card (e.g., credit card, debit card, or the like) through themagnetic card reader, which may use at least a portion of the paymentcard number to generate the pair ID. The pair ID may be, or include, thelast four digits of the payment card number, a hash of at least aportion of the payment card number, or the like. In embodiments in whichthe peripheral 104 includes a check reader, the pair ID may include atleast a portion of the account number on the check, at least a portionof an account number manually entered by the user, a hash of at least aportion of an account number, or the like. Any check or card may be usedto facilitate an open pairing operation, as the operation is not atransaction involving a payment. In a closed pairing operation, the pairrequest 202 may include an indication of the type of communication, anindication of a peripheral device type, and an identifier of theperipheral device 104.

In response to receiving the pair request 202, the pairing module 128processes the request 202 and provides a pair response 204 to theperipheral 104. In an open pairing operation, the pairing module 128stores the pair ID in the database 132, and associates the pair ID withthe peripheral device 104. Additional information may be stored in thedatabase, as well, as described more fully below with reference to FIG.3 . The pair response 204 may include, for example, an acknowledgementof receipt of the pair request 202 and an indication that the pairingmodule 128 is awaiting a communication from the payment UI 108. Inembodiments, as shown in FIG. 2 , the peripheral 104 may provide a pairconfirmation request 206 to the pairing module 128. This pairconfirmation request 206 may include, for example, an acknowledgement ofreceipt of the pair response 204 and a timeout indication that informsthe pairing module 128 of an amount of time that the peripheral device104 will wait for the pairing operation to be completed before severingits communication with the pairing module 128.

As is shown in FIG. 2 , the payment UI 108 provides a pair request 210to the pairing module 128. In embodiments, the pair request 210 mayinclude information such as a payment node ID, a payment nodecertificate, an indication of the type of communication (e.g., anindication that the communication includes a pair request), anindication of a payment UI type, and the like. The pair request 210 mayalso include the pair ID discussed above. For example, in a closedpairing operation, the peripheral device 104 may include a displaydevice (e.g., I/O device 138) that presents, to a user, the pair IDgenerated by the pairing module 128 so that the user may provide (e.g.,using a keyboard) the pair ID to the payment UI 108. Additionally, in anopen pairing operation, the payment card, check, or other informationsource that is used to generate the pair ID may also be used to providethe pair ID to the payment UI 108. For example, the payment node 112 mayinclude a card reader, check reader, or other input device (e.g., akeyboard) that can be used to provide the pair ID to the payment UI 108.In embodiments of an open pairing operation, the pair request 210 mayoccur, for example, before the pair request 202 such as where a userinitiates the pairing operation via the payment UI 108 by keying in apair ID (e.g., the last four digits of a payment card number) or swipesa payment card through a magnetic card reader coupled to the paymentnode 112.

The pairing module 128 receives and processes the pair request 210.Information from the pair request 210 may be stored in the database 132and associated with other information stored therein. The pairing module128 may also generate a unique payment UI ID (UIID) and associate theUIID with other information included in the pair request 210,information provided in the pair request 202, or the like. For example,the pairing module 128 may associate the UIID with the peripheral IDand/or the pair ID. Any number of additional, or alternative,associations may be established between various types of information inthe database 132 to facilitate the pairing operation. As shown in FIG. 2, the pairing module 128 may provide a pair confirmation response 210 tothe peripheral device 104 and a pair response 212 to the payment UI 108.The pair response 212 may include information that indicates whether thepairing operation was successful, the peripheral ID, and the like. Afterthe pairing operation is successfully completed, the payment UI 108 andthe peripheral device 104 may be utilized, in conjunction with theperipheral controller 126, to complete a transaction operation.

FIG. 3 is a schematic diagram depicting an illustrative transactionoperation in accordance with embodiments of the present invention. Atransaction may be initiated at the payment UI 108. For example, a user(e.g., a sales associate, cashier, or the like) may provide transactioninformation to the payment UI 108 by inputting the information using auser input device (e.g., a keyboard, mouse, keypad, or the like), byscanning a barcode, or the like. Additionally, in embodiments, atransaction operating may be initiated at a peripheral device 104 or106.

As shown in FIG. 3 , the payment UI 108 provides a transaction request(labeled “TX REQ”) 302 to the transaction module 144 of the peripheralcontroller 126. The transaction request 302 and/or any number of othercommunications illustrated in FIG. 3 may utilize web communicationtechniques such as, for example, Asynchronous JavaScript and XML (AJAX),JavaScript Object Notation (JSON), Asynchronous JavaScript and JSON(AJAJ), HTTP POST, or the like, and may utilize an interface such as anAPI (e.g., the UGI 142 and/or the PGI 130, shown in FIG. 1 ). Thetransaction request 302 may include at least a portion of thetransaction information provided to by the user and may includeadditional transaction information such as information generated by thepayment UI 108, information associated with a peripheral device 104 or106, or the like. Examples of transaction information include, withoutlimitation, a unique transaction identifier (ID), an identification ofthe subject matter (e.g., good or service) of the transaction, anidentification of one or more parties to the transaction, an indicationof an expected payment amount, information associated with a paymentplan, and the like.

As shown in FIG. 3 , the transaction module 144 receives the transactionrequest 302 and may, in embodiments, store a transaction identifier (ID)in the database 132 to establish a record corresponding with thetransaction. In embodiments, the transaction module 144 may initiate acorresponding transaction instance that can be used by the transactionmodule 144 to facilitate processing a payment request associated withthe transaction. In embodiments, the payment UI 108 may provide thetransaction request 302 to the payment processing system 116, which mayprovide the transaction request 302 to the transaction module 144 of theperipheral controller 126 and may include additional information withthe transaction request 304 such as, for example, an identifier (ID)associated with the payment processing system 116, a second transactionidentifier (ID) generated, or otherwise used, by the payment processingsystem, communication information (e.g., port IDs, security tokens,identifications of communication protocols), and the like.

As shown in FIG. 3 , the transaction module 144 receives paymentinformation 304 from the peripheral device 104. In embodiments, thetransaction module 144 may provide a payment information request to theperipheral device 104, which may prompt a user to provide paymentinformation. In other embodiments, a user may provide paymentinformation to the peripheral device 104 without being prompted. Paymentinformation 304 may include, for example, credit card information (e.g.,a credit card number, expiration date, and security code), debit cardinformation (e.g., a debit card number and personal identificationnumber (PIN)), check information (e.g., a scanned image of a check and achecking account number), or the like. The payment information 304 mayalso include, for example, a transaction ID corresponding to thetransaction initiated at the payment UI 108, a pair ID, a peripheral ID,and/or the like.

In embodiments, the transaction module 144 associates the paymentinformation 304 with the transaction information received in thetransaction request 302. As shown in FIG. 3 , the transaction module 144provides a payment request (labeled “PYMT REQ”) 306 to the paymentprocessing system 116. The payment request 306 includes at least aportion of the payment information 304 and may include at least aportion of the transaction information provided in the transactionrequest 302, any number of different types of identifiers (e.g.,transaction IDs, pair IDs), and/or the like. The payment processingsystem 116 processes the payment request 306 such as, for example, byprocessing a credit card payment, debit card payment, check payment, orthe like. In embodiments, the payment processing system 116 may interactwith payment gateways, third-party payment service vendors, banks orother financial institutions, and/or the like.

Additionally, in embodiments, the payment processing system 116 mayprovide a request (not shown) for additional payment information to thetransaction module 144, which may, in response, request the additionalinformation from the peripheral device 104. For example, the peripheraldevice 104 may include a magnetic card reader that reads paymentinformation 304 from a debit card or credit card, and the paymentprocessing system116 may further communicate a request to the peripheraldevice 104 for a PIN or signature, respectively. In this case, theperipheral device 104 may prompt the user for the PIN or signature, forexample, and provide the additional payment information (e.g., the PINor a digitally captured signature) to the transaction module 144, whichmay provide the same to the payment processing system 116. Any number ofrequests and responses such as these may be communicated among thepayment processing system 116, the transaction module 144, and theperipheral device 104 to facilitate processing a payment in accordancewith embodiments of the invention.

After successfully processing the payment request 306, the paymentprocessing system 116 may provide a confirmation (labeled “CONF”) 308 ofthe successfully processed payment request 306 to the transaction module144, which may provide a confirmation 310 of the successful payment tothe payment UI 108. The transaction module 144 may, in embodiments, alsoprovide a payment confirmation response 312 to the peripheral device 104(e.g., in embodiments in which the payment information 304 iscommunicated using HTTP POST, which expects a response). If a paymentrequest 306 is not successfully processed (e.g., due to insufficientfunds, communication errors, unsuccessful authentication or permissionprocedures, or the like), the confirmations 308, 310, and 312 mayindicate the unsuccessful attempt at processing the payment request 306.Additionally, in embodiments, the payment processing system 116 mayprovide a receipt (or instructions for printing a receipt) to thetransaction module 144, which may provide the receipt or instructions toa receipt printer. The receipt printer may, for example, be coupled to,or integrated with, the peripheral device 104, coupled to, or integratedwith, the payment node 112, or implemented as a separate peripheraldevice 104 or 106.

According to embodiments of the invention, a number of additionalpairing and transaction arrangements may be implemented. For example, anumber of device stations, each station having peripheral devices (e.g.,card readers, check readers, receipt printers, and the like) coupled toa peripheral hub, may be distributed about a sales floor.

Each station may have an associated barcode (or otherinformation-encoding image) that has a pair ID encoded therein. A salesclerk using a mobile device may move about with a customer, enteringitems into a payment UI executed on the mobile device. When the customeris ready to check out, the sales clerk may approach a device stationand, using a barcode scanner, camera, or other image-capturing deviceassociated with the mobile device, scan the barcode associated with thedevice station. The scanned barcode provides the pair ID to the paymentUI and, in response to receiving the pair ID, the payment UI mayinitiate a pairing operation that pairs the peripheral devices at thestation with the payment UI (e.g., by sending a pair request having thepair ID to a peripheral controller). In embodiments, the mobile devicemay have an associated barcode (or other similar image), and a barcodescanner at the device station may cause a peripheral-initiated pairingprocesses to be performed.

As described above, a peripheral controller may facilitate pairing aperipheral device with a payment UI to facilitate a transaction in whichthe payment UI does not receive payment information. FIG. 4 is a flowdiagram depicting an illustrative method 400 of facilitating atransaction in accordance with embodiments of the present invention.Embodiments of the illustrative method 400 include implementing apayment UI (e.g., the payment UI 108 shown in FIG. 1 ) at a payment node(e.g., the payment node 112 shown in FIG. 1 ) (block 410). The paymentUI may be implemented as a thin client application, a local application,or the like. For example, the payment node may include a computingdevice that hosts a web browser that may be used to present a web pagethat includes the payment UI, a POS device that implements the paymentUI using web services, or the like.

As shown in FIG. 4 , embodiments of the method 400 include pairing thepayment UI with a peripheral device (e.g., the peripheral device 104 or106 shown in FIG. 1 ) (block 420). A server (e.g., server 102 shown inFIG. 1 ) may be used to pair the payment UI with the peripheral deviceand may include, for example, a peripheral controller (e.g., theperipheral controller 126 shown in FIG. 1 ) that facilitates the pairingoperation. As discussed above, the pairing operation may include an openpairing operation, in which the peripheral device provides a pair ID, ora closed operation, in which the peripheral controller provides the pairID. Additionally, a pairing between a peripheral controller and apayment UI may be configured to persist for any desired period of timeand may be configured to be terminated upon any desired condition orevent. For example, in embodiments, pairings may be maintained untilchanged, or terminated, administratively.

According to embodiments of the method 400, the peripheral controllerreceives transaction information corresponding to a transactioninitiated at the payment UI (block 430). The payment UI may provide thetransaction information directly to the peripheral controller or mayprovide the transaction information to a payment processing system(e.g., the payment processing system 116 shown in FIG. 1 ), which mayprovide the transaction information to the peripheral controller. Theperipheral controller receives payment information from the peripheraldevice (block 440) and associates the transaction information with thepayment information to create a payment request (block 450). As shown inFIG. 4 , the peripheral controller provides the payment request to thepayment processing system (block 460), which processes the paymentrequest. The payment processing system may provide a confirmationindicating whether the payment was successful. In embodiments, thepayment processing system may provide receipt information to theperipheral controller, which can provide the receipt information to aperipheral printer. In this manner, the peripheral controller may alsofacilitate printing transaction receipts so that the payment UI is notexposed to the receipt information.

While embodiments of the present invention are described withspecificity, the description itself is not intended to limit the scopeof this patent. Rather, the inventors have contemplated that the claimedinvention might also be embodied in other ways, to include differentsteps or features, or combinations of steps or features similar to theones described in this document, in conjunction with other technologies.

The following is claimed:
 1. A method comprising: establishing, on atleast one cloud-based server, pairing relationships between a pluralityof peripheral devices and a plurality of payment user interfaces (UIs),wherein the pairing relationships comprise associations betweenrespective peripheral devices of the plurality of peripheral devices andrespective payment user UIs of the plurality of payment UIs, wherein atleast a portion of the associations between respective peripheraldevices of the plurality of peripheral devices and respective paymentuser UIs of the plurality of payment UIs are based on peripheral IDsthat uniquely identify respective peripheral devices and identifiersthat identify respective payment UIs; receiving, on the at least onecloud-based server, a transaction request from a requesting payment UIof the plurality of payment UIs including transaction informationcorresponding to a payment transaction; determining, on the at least onecloud-based server, a paired peripheral device of the plurality ofperipheral devices corresponding to the requesting payment UI based onone or more pairing relationships in the database to establish acloud-based virtual connection between the paired peripheral device andthe requesting payment UI, wherein a display on which the requestingpayment UI is to be displayed and paired peripheral device are local toeach other, but geographically remote from the cloud-based server;requesting, on the at least one cloud-based server, payment informationfrom the paired peripheral device of the plurality of peripheral devicesbased on the transaction information received from the requestingpayment UI; receiving, on the at least one cloud-based server, paymentinformation from the paired peripheral device of the plurality ofperipheral devices; and associating, on the at least one cloud-basedserver, the transaction information with the payment information tocreate a payment request to be provided to a payment processing system.2. The method of claim 1, wherein the transaction request includes aunique transaction identifier (ID).
 3. The method of claim 2, whereinthe transaction request further includes one or more of anidentification of the subject matter of the transaction, anidentification of one or more parties to the transaction, an indicationof an expected payment amount, or information associated with a paymentplan.
 4. The method of claim 2, further comprising receiving a requestfor additional payment information not included in the payment requestfrom the payment processing system and, responsive to the request foradditional payment information from the payment processing system,sending a request for the additional payment information requested bythe payment processing system to the paired peripheral device.
 5. Themethod of claim 4, wherein the request for additional paymentinformation comprises one or more of a PIN or a signature.
 6. The methodof claim 1, further comprising receiving a successful paymentconfirmation from the payment processing system indicating successfulpayment to a merchant associated with the requesting payment UI, andresponsive to the successful payment confirmation, sending a message toone or more of the requesting payment UI or paired peripheral deviceindicating successful processing of payment to the merchant.
 7. Themethod of claim 1, further comprising receiving a unsuccessful paymentnotification from the payment processing system indicating unsuccessfulpayment processing to a merchant associated with the requesting paymentUI, and responsive to the unsuccessful payment notification, sending amessage to one or more of the requesting payment UI or paired peripheraldevice indicating unsuccessful processing of payment to the merchant. 8.The method of claim 1, further comprising preventing payment informationreceived from the paired peripheral device from being communicated tothe requesting payment UI.
 9. The method of claim 1, wherein theidentifiers in the database that identify respective payment UIs arebased on one or more of a payment node identifier (ID), a payment nodecertificate, a payment UI type indicator, a pair identifier (UI), or apayment UI identifier (UIID).
 10. One or more non-transitory,computer-readable storage media comprising a plurality of instructionsstored thereon that, in response to being executed, cause a computingdevice to: establish pairing relationships between a plurality ofperipheral devices and a plurality of payment user interfaces (UIs),wherein the pairing relationships comprise associations betweenrespective peripheral devices of the plurality of peripheral devices andrespective payment user UIs of the plurality of payment UIs, wherein atleast a portion of the associations between respective peripheraldevices of the plurality of peripheral devices and respective paymentuser UIs of the plurality of payment UIs are based on peripheral IDsthat uniquely identify respective peripheral devices and identifiersthat identify respective payment UIs; receive a transaction request froma requesting payment UI of the plurality of payment UIs includingtransaction information corresponding to a payment transaction;determine a paired peripheral device of the plurality of peripheraldevices corresponding to the requesting payment UI based on one or morepairing relationships in the database to establish a cloud-based virtualconnection between the paired peripheral device and the requestingpayment UI, wherein a display on which the requesting payment UI is tobe displayed and paired peripheral device are local to each other, butgeographically remote from the cloud-based server; request paymentinformation from the paired peripheral device of the plurality ofperipheral devices based on the transaction information received fromthe requesting payment UI; receive payment information from the pairedperipheral device of the plurality of peripheral devices; and associatethe transaction information with the payment information to create apayment request to be provided to a payment processing system.
 11. Theone or more non-transitory, computer-readable storage media of claim 10,wherein the transaction request includes a unique transaction identifier(ID).
 12. The one or more non-transitory, computer-readable storagemedia of claim 11, wherein the transaction request further includes oneor more of an identification of the subject matter of the transaction,an identification of one or more parties to the transaction, anindication of an expected payment amount, or information associated witha payment plan.
 13. The one or more non-transitory, computer-readablestorage media of claim 11, further comprising one or more instructionsto receive a request for additional payment information not included inthe payment request from the payment processing system and, responsiveto the request for additional payment information from the paymentprocessing system, send a request for the additional payment informationrequested by the payment processing system to the paired peripheraldevice.
 14. The one or more non-transitory, computer-readable storagemedia of claim 13, wherein the request for additional paymentinformation comprises one or more of a PIN or a signature.
 15. The oneor more non-transitory, computer-readable storage media of claim 10,further comprising one or more instructions to receive a successfulpayment confirmation from the payment processing system indicatingsuccessful payment to a merchant associated with the requesting paymentUI, and responsive to the successful payment confirmation, send amessage to one or more of the requesting payment UI or paired peripheraldevice indicating successful processing of payment to the merchant. 16.The one or more non-transitory, computer-readable storage media of claim10, further comprising one or more instructions to receive aunsuccessful payment notification from the payment processing systemindicating unsuccessful payment processing to a merchant associated withthe requesting payment UI, and responsive to the unsuccessful paymentnotification, send a message to one or more of the requesting payment UIor paired peripheral device indicating unsuccessful processing ofpayment to the merchant.
 17. The one or more non-transitory,computer-readable storage media of claim 10, further comprising one ormore instructions to prevent payment information received from thepaired peripheral device from being communicated to the requestingpayment UI.
 18. The one or more non-transitory, computer-readablestorage media of claim 10, wherein the identifiers in the database thatidentify respective payment UIs are based on one or more of a paymentnode identifier (ID), a payment node certificate, a payment UI typeindicator, a pair identifier (UI), or a payment UI identifier (UIID).